Define functional model.
Functional Model: Definition and Purpose
A functional model is a representation of a software system that describes the transformations of data as it flows through the system. It focuses on what the system does rather than how it does it, emphasizing the functions that convert inputs into outputs regardless of the implementation details. The functional model captures the processing aspects of a system, highlighting data transformations and the functional dependencies between processes.
In software engineering, the functional model is one of the core models used during system analysis and design, alongside object models (which focus on system structure) and dynamic models (which focus on system behavior over time).
Key Components of a Functional Model
1. Functions/Processes
Functions are the transformational elements that:
- Accept input data
- Process or transform the data
- Produce output data
Each function represents a specific operation or computation that the system performs.
2. Data Flows
Data flows represent the movement of data through the system:
- Connections between functions
- Inputs from external entities
- Outputs to external entities
- Data movement between processes and data stores
3. External Entities
External entities (also called terminators) are the sources or destinations of data that exist outside the system boundary:
- Users
- Other systems
- External organizations
- Hardware devices
4. Data Stores
Data stores represent repositories where data is held for later use:
- Databases
- Files
- Temporary storage
- Queues and buffers
Representation Techniques for Functional Models
1. Data Flow Diagrams (DFDs)
The most common technique for representing functional models is through Data Flow Diagrams. DFDs use a set of standardized symbols:
- Processes (circles or rounded rectangles): Represent functions that transform data
- Data Flows (arrows): Show the movement of data
- External Entities (rectangles): Depict sources or destinations of data outside the system
- Data Stores (open-ended rectangles): Represent repositories of data
DFDs typically use a leveled approach:
- Context Diagram (Level 0): Shows the system as a single process with its external entities
- Level 1 DFD: Breaks down the main process into major functional processes
- Level 2+ DFDs: Further decompose complex processes into simpler ones
Example: Context Diagram (Level 0) for an Order Processing System
┌─────────────┐ ┌─────────────────────┐ ┌───────────┐
│ │ Order │ │ Payment │ │
│ Customer ├──────────►│ Order Processing │◄──────────┤ Bank │
│ │ │ System │ │ │
│ │◄──────────┤ ├──────────►│ │
└─────────────┘ Confirmation│ │Transaction└───────────┘
│ │ Data
└─────────┬───────────┘
│
│ Shipping
│ Request
▼
┌───────────────────┐
│ │
│ Shipping │
│ Department │
│ │
└───────────────────┘
Example: Level 1 DFD for the Order Processing System
┌─────────────┐ ┌───────────┐ ┌───────────┐
│ │ Order │ │ Verified │ │
│ Customer ├─────────►│ Validate │─────────►│ Process │
│ │ │ Order │ │ Payment │◄────┐
└─────────────┘ └───────────┘ └─────┬─────┘ │
│ │
│ │ Payment
│ │ Authorization
┌─────────────┐ │ │
│ │ │ │
│ Customer │◄────────────────────┐ │ │
│ │ Confirmation │ │ │
└─────────────┘ │ │ │
│ │ │
│ │ │
│ ▼ │
┌───────────────────┐ ┌─────┴────┐ ┌───────────┐
│ │ Shipping │ │ │ │
│ Shipping │◄──────────────┤ Fulfill │ │ Bank │
│ Department │ Request │ Order │ │ │
│ │ │ │ │ │
└───────────────────┘ └──────────┘ └───────────┘
▲
│
│
┌────┴────┐
│ │
│ Product │
│ Database│
│ │
└─────────┘
2. Function Hierarchies
Function hierarchies organize system functions in a top-down structure:
- Top-level functions represent major system capabilities
- Lower levels show increasingly detailed sub-functions
- Typically represented as a hierarchical tree or structure chart
┌───────────────────┐
│ Order Processing │
│ System │
└─────────┬─────────┘
┌───────────────────┼────────────────────┐
│ │ │
┌───────────▼───────┐ ┌────────▼─────────┐ ┌──────▼──────┐
│ │ │ │ │ │
│ Customer │ │ Order │ │ Inventory │
│ Management │ │ Management │ │ Management │
│ │ │ │ │ │
└─────────┬─────────┘ └──────┬───────┬───┘ └─────────────┘
│ │ │
┌────────┴────────┐ ┌────▼───┐ │
│ │ │ │ │
│ Register │ │ Create │ │
│ Customer │ │ Order │ │
│ │ │ │ │
└─────────────────┘ └────────┘ │
│
┌───────▼──────┐
│ │
│ Process │
│ Payment │
│ │
└──────────────┘
3. IDEF0 (Integration Definition for Function Modeling)
IDEF0 is a more formal modeling technique that shows:
- Functions: As boxes
- Inputs: Arrows entering the left side of a function
- Outputs: Arrows exiting the right side
- Controls: Arrows entering the top (constraints)
- Mechanisms: Arrows entering the bottom (resources)
Controls
│
▼
Inputs ──────►┌───────────┐─────────► Outputs
│ │
│ Function │
│ │
└─────┬─────┘
│
▼
Mechanisms
4. Activity Diagrams
UML Activity Diagrams can also be used to model functional aspects of a system:
- Show the flow of activities
- Include decision points and parallel paths
- Can represent complex processing logic
Levels of Functional Models
A comprehensive functional model is typically developed at multiple levels of abstraction:
1. High-Level Functional Model
- Identifies major system functions
- Shows primary data flows between functions
- Establishes system boundaries
- Identifies external entities
2. Detailed Functional Model
- Decomposes high-level functions into subfunctions
- Specifies detailed data flows
- Identifies all data stores
- Describes transformations in more detail
3. Process Specifications
- Provides algorithms or rules for each atomic function
- Describes the logic using pseudocode, structured English, decision tables, or state transition diagrams
Benefits of Functional Modeling
- Focused on System Behavior: Emphasizes what the system does, making it easier to validate with users
- Abstraction from Implementation: Separates functionality from implementation details
- Hierarchical Decomposition: Supports the systematic breakdown of complex systems
- Communication Tool: Provides a visual representation understandable by non-technical stakeholders
- Requirements Validation: Helps verify that all required functionality is included
- Identification of Data Elements: Helps identify data that needs to be stored or transmitted
Limitations of Functional Modeling
- Limited Representation of Time: Does not explicitly show timing or sequencing
- Weak on Data Structure: Focuses on data flow rather than data organization
- No Object Representation: Does not reflect object-oriented concepts
- Static View: Provides a static rather than dynamic view of the system
- May Lead to Functional Decomposition: Can encourage a function-centric design approach
Relationship with Other Models
The functional model is typically used in conjunction with other models to provide a complete view of the system:
- Object Model: Describes the system's structure in terms of objects, attributes, and relationships
- Dynamic Model: Shows the system's behavior over time through state changes and event sequences
- Data Model: Represents the data structures and relationships independent of processing
Together, these models provide complementary perspectives that address different aspects of the system under development.
Application in Software Development Process
The functional model is particularly useful during:
- Requirements Analysis: Understanding what the system needs to do
- System Design: Decomposing the system into manageable components
- Validation: Verifying that all required functions are addressed
- Documentation: Providing system documentation for future reference
- Maintenance: Understanding the impact of changes on system functions
In modern software development practices, functional modeling continues to be a valuable technique, particularly in systems where data processing is complex or critical to the application domain.